Skip to content

modified changes for datetime and NaT Objects Behavior closes #43280 #43289

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

Navaneethan2503
Copy link

@Navaneethan2503 Navaneethan2503 commented Aug 29, 2021

**Modified datatime object 👍 **
i have changed view values to numeric of date and missing data found in pd series is returns Nan when coerce errors .

**Example for solved changes 💯 **

>>> pd.to_numeric(pd.Series(datetime(2021, 8, 22)), errors="coerce")
[OUT]
0    20210822
dtype: int64

>>> pd.to_numeric(pd.Series(pd.NaT), errors="coerce")
[OUT]
0   NaN
dtype: float64

>>> s = pd.to_numeric(datetime(2021, 8, 22), errors="coerce")
0 20210822
dtype: Int64
>>> s = pd.to_numeric(pd.NaT, errors="coerce")
 nan

@pep8speaks
Copy link

pep8speaks commented Aug 29, 2021

Hello @Navaneethan2503! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

Line 162:23: E271 multiple spaces after keyword
Line 185:14: W291 trailing whitespace

Line 795:5: E265 block comment should start with '# '
Line 800:1: E302 expected 2 blank lines, found 1
Line 801:5: E265 block comment should start with '# '
Line 806:1: E302 expected 2 blank lines, found 1
Line 807:5: E265 block comment should start with '# '
Line 812:1: E302 expected 2 blank lines, found 1
Line 813:5: E265 block comment should start with '# '
Line 816:1: W391 blank line at end of file

Comment last updated at 2021-08-31 14:28:48 UTC

@Navaneethan2503 Navaneethan2503 changed the title BUG: modified changes for datetime and NaT Objects Behavior closes #43280 modified changes for datetime and NaT Objects Behavior closes #43280 Aug 29, 2021
@hec10r
Copy link

hec10r commented Aug 29, 2021

Hi @Navaneethan2503, thank you for this PR. I think that this solves the problem for pd.NaT, but there is still an inconsistency for scalar arguments vs pd.Series:

>>> import pandas as pd
>>> from datetime import datetime
>>> pd.to_numeric(pd.Series(datetime(2021,8,22)), errors="coerce")
0    20210822
dtype: int64
>>> pd.to_numeric(datetime(2021,8,22), errors="coerce")
nan

Additionally, I am not sure that the idea is to change the current behavior of datetime series for a new one. Instead, the idea should be to apply the current behavior to scalar arguments.

Copy link

@Kavyasilam Kavyasilam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good approach @Navaneethan2503

@Kavyasilam
Copy link

Hi @Navaneethan2503, thank you for this PR. I think that this solves the problem for pd.NaT, but there is still an inconsistency for scalar arguments vs pd.Series:

>>> import pandas as pd
>>> from datetime import datetime
>>> pd.to_numeric(pd.Series(datetime(2021,8,22)), errors="coerce")
0    20210822
dtype: int64
>>> pd.to_numeric(datetime(2021,8,22), errors="coerce")
nan

Additionally, I am not sure that the idea is to change the current behavior of datetime series for a new one. Instead, the idea should be to apply the current behavior to scalar arguments.

I thing all scalar argument are passed , my suggestion idea is good because datatime behaviour are all type passed

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

always always start with tests that fail w/o the change and pass with

@Navaneethan2503
Copy link
Author

Final PR pass all scalar arguments including datetime and NaT DataType , make it merge

Copy link
Member

@simonjayhawkins simonjayhawkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the expected behavior is still being discussed? This is breaking tests.

Copy link
Member

@simonjayhawkins simonjayhawkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you have requested review but I see no changes since the previous review and ci is failing?

also can you move the tests from the docstring to pandas/tests and add a release note

@@ -267,7 +267,7 @@ Datetimelike
^^^^^^^^^^^^
- Bug in :class:`DataFrame` constructor unnecessarily copying non-datetimelike 2D object arrays (:issue:`39272`)
- :func:`to_datetime` would silently swap ``MM/DD/YYYY`` and ``DD/MM/YYYY`` formats if the given ``dayfirst`` option could not be respected - now, a warning is raised in the case of delimited date strings (e.g. ``31-12-2012``) (:issue:`12585`)
-
-Bug in :class:'Series and scalar' to_numeric as inconsistent behaviour for datatime object (:issue:'43280')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mroeschke
Copy link
Member

Thanks for the PR but it appears this is a duplicate of #43315 which is a little further along. Closing as a duplicate but happy to have you work on other issues with a good first issue label.

@mroeschke mroeschke closed this Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: pd.to_numeric has an inconsistent behavior for datetime objects
7 participants